【レポート】Optimizing the world's top apps: How Meta tests using AWS Device Farm #AWSreInvent #FWM204

こんにちは。クラスメソッドのハウンです🐏

今日は AWS re:Invent 2024 "世界最高のアプリ最適化:AWS Device Farmを使ったMetaのテスト方法" セッションのレポートを書きます。

本セッションでは、モバイルアプリテストサービスAWS Device Farmについて、Facebookの会社として有名なMetaの事例とともに紹介しました。

このセッションでは、AWS Device Farmを通じて実際のデバイスで大規模にテストを実行し、モバイルおよびウェブアプリの品質を向上させる方法を学びます。 先導的なソーシャルメディア会社であるMetaがDevice Farmを使用したモバイルアプリのテストプロセスを簡素化、モバイルアプリとSDKの品質改善、クラウド上の実際のデバイスで自動化および手動テストを実行して、問題をより早く識別して修正し、アップデートをより頻繁にリリースする方法について聞いてみてください。

セッション動画は YouTubeに公開されてますので、ご参考まで。

セッション内容

モバイルアプリテストの課題

まず、モバイルアプリの開発後にテストを行う状況だと仮定します。開発者は画面サイズ、GPU、モデル、OSなど様々な要因を考慮して実際の機器を購入すると思います。購入した機器を利用してテストを行った時、期待していた結果と異なる現象が発生した場合、特定の機器だけで発生するのか、特定のOSだけで発生するのか、その他の条件によって発生するのか導出する過程を通じて、アプリに問題がないのかを確認することになります。

このようなテスト過程は、人の力である程度可能ですが、時間と費用が多くかかります。

AWS Device Farmとは?

AWS Device Farmは、モバイル端末とデスクトップブラウザを大規模にテストできる完全管理型アプリケーションテストサービスです。

AWS Device Farmは、リモート接続で自動化されたテストが可能です。Chrome、Firefox、Microsoft Edgeなど複数のデスクトップブラウザバージョンを提供しており、デスクトップブラウザのテストにも容易です。

つまり、テストのためにはipaやapkのようなアプリケーションファイルとテストフレームワークだけを準備すれば良いです。

各端末は独立した環境で実行するため、より正確な結果を得ることができます。

Metaでのテスト事例

Metaで開発者として働いている方が事例について発表してくださいました。

まず、Metaの配信フローについて説明していました。

コードを書き終えたら、IDEからコードに対するフィードバックが来ます。これらを修正する過程を進めます。この過程でビルドに問題がなければ、ユニットテストを実行するか、エミュレータでテストを行うか、E2Eテストを実施します。コードレビューを提出した場合、レビュー中に簡単なE2Eテストとユニットテストを実行します。レビューが通ったら、メインブランチに統合し、再びメインブランチでE2Eテストを実行して何の問題もないか確認します。ビルドがリリース候補に昇格すると、手動テストのためにQAチームに送られるか、Metaの開発マシンへ内部的に配布されます。すべて良さそうで、バグがなければ、リリース準備が完了するとのことです。

このような過程が順調に進めばいいのですが、常に理想的な状況に流れていくわけではありません。 実際には、単純なバグが発売パイプラインで非常に遅く発見され、問題が発生するそうです。

開発したアプリを機器にインストールした場合、端末の使用する上で限界が生じます。この限界は、AndroidとiOSなどのプラットフォームの違いや、機種やエミュレータ、特定の環境でのみ実行されるコードの影響によっても発生するため、その要因を一から調べるには手間がかかります。そして、GPUの問題も存在しますが、実際のスマートフォンとエミュレーターのGPU性能の違いにより、動きの違いが発生します。

この問題点についてですが、AWS Device Farmが提供するデバイスを通じて、実際のスマートフォン機器を使用するのと同じ環境でテストが可能ということで解決ができたとのことでした。

パフォーマンスを測定するとき、システムノイズが発生することが多いのですが、このノイズを最小限に抑える必要があります。 そのため、ノイズを最小化する技術を適用してグラフがはるかに性能低下を滑らかに感知できるようになったそうです。

また、Metaではサーバーからの呼び出しの影響を最小限に抑えるために、ローカルプロキシを通じて、アプリのすべてのリクエストを記録したり、サーバーに対するリクエストと応答を記録しているそうです。これは、AWS Device Farmへのカスタマイズ機能を通じて実現することが可能だったとのことです。

そして、Metaではデータ収集のために少なくとも50個の評価版を実行し、各評価版ごとの違いを比較しますが、AWS Device Farmで提供する2時間30分の制限時間内に確認することが可能だったそうです。

その他にも、ルートデバイスで強制的にアプリを終了したり、アプリのディスク状態をスナップショットで撮影して、各評価版の前バージョンに復元し、ディスクのノイズを減少させることもできるという部分についても言及しました。

MetaではCPU周波数変化の影響を最小化するために、手動でCPUが過熱しない値に調整しておくそうです。また、周波数の変化がないか確認するために、テストの前後にCPU周波数チェーンが何倍変更されたかの値を読み込み、この2つの値が一致しない場合は、テストを無効にします。この機能はAWS Device Farmが提供するルートデバイスを有効に使える要素になったとのことでした。

What's new

最後にAWS Device Farmのアップデート内容について紹介されました。

iOSアプリのXCTest UIがサポートされ、ipaファイルだけでテストが可能になリマした。XCTest形式でテストをする場合、zip形式でファイルをアップロードする必要がありますが、XCTest UIは両方の方式でサポートされます。

その他、サービス性能自体が向上した部分や、従属性設定の簡素化、コンソールの改善、エラーデバッグとビデオストリーミング機能が改善されました。

最後に

AWS内では本当に珍しいモバイル関連サービスに関するセッションでしたが、私が聞いたセッションの中では背景知識がある分野なので、最も興味深く聞いたセッションでした。

AWS Device Farmがリリースされてからほぼ10年ほど経ったほど、かなり古いサービスですが、このセッションを申し込むまでは存在についてよく知らなかったことに少し反省するきっかけにもなりました。
テスト用の端末がないときに活用することができたり、Appiumを使えばお互いに違うプラットフォームのコードでも一つのテストコードでテストができるという大きな利点を持っていて、iOSとAndroidの両方をサポートするアプリで活用性が良さそうだと感じました。

Metaの事例とともにAWS Device Farmについて新しく知ることができ、とても有益な時間でした！